1. The Field of the Invention
The field of the present invention is computer software driver development. The present invention relates to tools, software frameworks, conventions, etc. to simplify code generation of drivers and provide standardized access points. More specifically, the present invention relates to standardized methods, computer program products, and data structures to create hierarchal relationships between file objects.
2. Present State of the Art
A given software driver executable code implementation may have multiple entry points to different portions of functionality. Once loaded and controlled by an operating system such as Microsoft(copyright) Windows NT(trademark), specific system objects are created representing the driver (driver objects), the xe2x80x9cdevicesxe2x80x9d or specific functional definitions accessible by other components supported by the driver (device objects), and instances of the driver functionality actually used by a component (typically in the form of file objects).
Most operating systems, including Windows NT, implicitly assume that a driver performs a single type of function and that all device objects created in connection with the driver will perform the function in the same manner. Furthermore, created file objects, whether created under the device objects or under other file objects, are assumed to be serviced in the same way. Because of the above mentioned assumptions, the Windows NT operating system and other like operating systems use a single driver object to share all entry points with all sibling device objects created using the same driver object.
As a result of such assumptions, each driver developer must write specific code to validate initial file object requests in systems where hierarchically related file objects may be created according to a specific set of rules. One example of a such a file object hierarchy is the driver connection system described in detail hereafter. This driver connection system is shown by way of example and not by limitation and any other system that makes use of the present invention as hereafter explained will be considered within the scope of the present invention as claimed.
This problem is exacerbated when a standardized system of writing device drivers is used as is found in the driver connection system. Since all driver developers are writing to the same set of rules, not only is specific code required to handle the file object creation but it is developed many times over by each developer writing drivers according to the standardized convention.
Another problem resulting from the basic assumption that all file objects are serviced in the same manner is ensuring that a processing request is routed to the correct handler for a particular file object. Since different functionality can be imparted to a driver, and such functionality is accessed by opening a xe2x80x9cfilexe2x80x9d on the particular device that creates an underlying file object in the system for managing the state of that file and provides a file handle as an access mechanism for directing I/O requests, different processing request handlers are used depending on the file (and file object) designated to receive the request. Special code must normally be written to perform such routing to overcome the assumption of homogenous operation. Again, in a standardized system where multiple different manufacturers may be writing drivers with hierarchically related functionality, the impact is magnified since the special code must be written from scratch multiple times.
What is needed is a standardized mechanism for validating creation requests of file objects in a hierarchically related system of file objects and a way to route processing requests to the correct handler for a given file object.
It is an object of the present invention to provide a standardized mechanism for validating file object create requests based on context information accessible by reference in system device objects and file objects that can be used by multiple third party software driver developers.
It is another object of the present invention to route processing requests to the appropriate handler for a given file object in a standardized fashion to facilitate interoperating device driver development by multiple third party developers.
It is yet another object of the present invention to provide a framework for third party driver developers that reduces the amount of coding effort to develop software drivers and assist in developing drivers that may handle processing requests in a standardized fashion.
Additional objects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objects and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims.
To achieve the foregoing objects, and in accordance with the invention as embodied and broadly described herein a method, computer program product, and data structure for validating creation of and routing messages to file objects are provided. There is established a system level convention that all third party software driver developers follow, along with standardized data structures and code that allow easy development of software drivers. These aspects of the invention efficiently provide different types of functionality within the same driver, hierarchically related functionality through validated file object creation, and correct routing of processing messages to the correct handler routines.
The invention extends to a plurality of request handling multiplexing functions, each referenced from the driver object depending on the type of message received (create, I/O control, close, etc.). These multiplexing functions are not developed by the third party developers but rather are provided as part of the system by the system developer or some other entity. The driver developers reap benefits from the standard multiplexing functions by writing software drivers that conform to the established convention and utilize predefined data structures.
According to the present invention, a private storage area in the device objects and the file objects is used to reference predefined data structures that are written by the third party driver developer. The driver developer creates and xe2x80x9cfillsxe2x80x9d the data structures, including writing the specific message handlers that are needed for a particular file object type and message type, without writing any of the code to validate the file object creation or route incoming messages to the correct message handler function. The validation and routing functionality are found in the multiplexing dispatch functions already provided.
For example, a device object private data area references, through a pointer or other means, a validation table data structure containing a table of valid file object types and pointers to appropriate create handlers for creating file objects of the corresponding type. When a create message is received by the create multiplexing dispatch function, the validation table data structure is accessed to determine the validity of the request and, if valid, access the correct create handler.
Should the message indicate that a xe2x80x9cparentxe2x80x9d file object exists, the create multiplexing dispatch function accesses the parent file object""s private data area for a reference to another data structure. The file object data structure contains pointers to all the appropriate message handlers for that particular file object.
With respect to the create message handler, reference is made through a pointer or other means to a validation table data structure containing valid file object types and pointers to appropriate create handlers for creating file objects of the corresponding type. When a create message is received by the create multiplexing dispatch function, the validation table data structure is accessed from the file object data structure to determine the validity of the request and, if valid, access the correct create handler.
Because of the validation tables associated with a file object and a device object, any create request or message may be validated by the create multiplexing dispatch function before being sent to the appropriate create handler. Again, a driver developer is freed from writing the validation code and simply signifies the valid types of file objects in the corresponding data structures either by index ranges or actual type strings used for comparison. If a received message does not correspond to any of the specifically enumerated valid types of file objects, a default or wildcard entry in the validation tables can be invoked, resulting in a default create handler being used or in an error message being generated.
Each file object data structure also contains, as mentioned previously, references to the message handlers for each type of message that pertain to this particular file object. In this manner, the multiplexing dispatch function for a particular message type may route the message to the correct handler for a given file object. Again, the driver developer does not need to write the routing code but can simply use the multiplexing dispatch function and the file object data structure to reference the appropriate message handlers.
In one implementation of the invention, create file object requests can include a pointer to a private data structure defined by the third party driver developer. The private data structure can include parameters or attributes specifically related to the file object type associated with the create request. In this manner, the parameters or attributes included in the private data structure can be passed to the create handler invoked for creating the requested file object, thereby providing an added degree of flexibility or customization for driver developers, while maintaining a standardized framework for file object creation and messaging validation.
These and other objects and features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.